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© The present invention provides a method for 
processing, handling and presenting data pertaining 
to an enterprise in the form of a data model. The 
data within that model and the relationships are 
presented, looked-at and used from two different 
points of view, from an application point of view that 
identifies which entities are used by individual pro- 
gram applications, and from an entity point of view 
which identifies all existing entities within a program 
series and their relationships at the different levels of 
decomposition independently of any application. 
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The invention pertains to a meU for # process- 
ing, handling, presenting data per^Pig to an en- 
terprise, especially a manufacturing enterprise, in 
the form of a data model, in order to improve the 
understanding of business processes. 

Th immense growth of data and applications 
in enterprises, especially also in manufacturing en- 
terprises, leads to exorbitant problems in data stor- 
age and data usage. This kind of chaos is de- 
scribed e. g. in the preface of the book "Aufbau 
betrieblicher Informationssysteme mittels konzep- 
tioneller Datenmodellierung ,, by Max Vetter, 6. 
Auflage. Teubner Verlag. Stuttgart, to be the prob- 
lem of the century. In this article this problem is 
defined as coping with the data chaos which came 
up nearly everywhere due to historically uncontrol- 
led grown data masses. This asks for providing a 
basis that Effectively uses possibilities of the in- 
formation technique which points far in the future. 
Such a basis could be an enterprise-wide data 
model. 

It is the object of the present invention to 
provide a data model that is able to contribute in 
solving the problem of uncontrolled growth of data 
in enterprises, especially in manufacturing enter- 
prises. The invention solves these problems in ad- 
vantageous manner by applying the features laid 
down in the independent claim. Further advanta- 
geous embodiments are laid down in the sub- 
claims. 

The given modelling in accordance with the 
present invention provides an understanding of the 
pr sent and future business activities of an enter- 
prise. Thus, for example the data model for the 
manufacturing industry provides a consistent view 
of data across the enterprise, helps to prevent data 
redundancy, enables the sharing of data, simplifies 
the development of application programs, and also 
facilitates an open end user access to the data. 

The present invention provides a method for 
processing, handling and presenting data pertain- 
ing to an enterprise in the form of a data model. 
The data within that model and the relationships 
are presented, lodked-at and used from two dif- 
ferent points of view, from an application point of 
view that identifies which entities are used by in- 
dividual program applications, and from an entity 
point of view which identifies all existing entities 
within an enterprise and their relationships at the 
different levels of decomposition independently of 
any application. 

The benefits given by the present invention 
can be seen in that an overview of organization 
structures and dependency of an enterprise is giv- 
en in a graphical view. Furthermore, information is 
shown in a clear, distinct way. The data model in 
accordance with the present invention serves as a 
basis to compare the enterprises data structures to 



standard data strucftj^. It also helps a customer 



to manage his growtl^^computer integrated man- 
ufacturing. Furthermore, it is valuable in giving 
know-how of application and its related data con- 
s tests, structure and relations. It also is reliable in 
representing design results that ar us able as 
basis for the development of a seri s of application 
programs, as for example partly given by the ap- 
plication program of the IBM CIM Production Pro- 
w gram Series. 

The invention will be described in more detail 
in connection with an embodiment shown in the 
drawing in which 

Fig. 1 shows an overview of the data model 
is structure in accordance with the 

present invention; 
Fig. 2 shows schematically the application 
view; 

Rg. 3 shows schematically the entity view; 
20 Rg. 4 shows schematically the different re- 
lationship representation used in the 
inventive data model; 
Rg. 5 shows schematically the relationship 
between the data model and a rela- 
25 tional data base; 

Rg. 6 shows a possible application struc- 
ture; 

Rg. 7 shows CIM architecture elements; 

Rg. 8 (formed by Fig. 8A and 8B) shows 
30 defined entity types; 

Rg. 9 shows schematically the structure of 
the engineering application area and 
the associated business objects and 
entity groups; 

35 Rg. 10 shows the engineering business ob- 
jects addressed by engineering with 
their different relationships; 
Rg. 1 1 shows the entity groups addressed 
by engineering with their different re- 
40 lationships; 

Rg. 12 shows the entity group "Bill of Ma- 
terial"; 

Rg. 13 shows the business object product 
with its entities and their different 
45 relationships; 

Rg. 14 shows the entities belonging to the 
entity group item and its different 
relationships; 
Rg. 15 shows the entities of the entity group 
so item sales data with its different rela- 

tionships. 

Rg. 1 shows in an schematic overview the 
scope of the data model 10 in accordance with the 
present invention. Data model 10 encompasses an 
55 application view 11 and may additionally or as an 
alternative include an entity view 12. The applica- 
tion view 11 includes logical application models 
which represent and support current and already 
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available applications. Those ^tolications can be 
shown in graphical form in ^pcation area dia- 
grams 15 or in single application diagrams 16. The 
application view 1 1 also includes the conceptional 
view 14. In the conceptional view 14 there are 
future applications or conceptional application 
models which can be seen as extensions of al- 
ready existing applications or of completely new 
applications. Those future applications can also be 
shown in single application diagrams 16. As in- 
dicated by arrow 17 the application area diagrams 
15 contain corresponding business objects 18. Fur- 
thermore, as indicated by arrow 19 the application 
area diagrams 15 also contain corresponding entity 
groups 20. The single application diagrams contain 
corresponding data groups 22 as indicated by ar- 
row 21. The data groups Z2 are specified by at- 
tributes'^. In addition to the two types of models, 
the logical view 13 and the -conceptional view 14, 
the program series data model 10 provides the 
entity view 12 encompassing business object dia- 
grams 24 and entity group diagrams 25. These 
different entity types define and represent data at 
different composition levels. Each business object 
diagram 24 shows all entity groups 20 which built 
the business object. Furthermore, it shows ail other 
business objects which are related to it. Each entity 
group diagram 25 shows ail data groups 22 which 
belong to the entity groups. Furthermore, it shows 
all other entity groups which have relationships to 
it. As indicated by double arrow 26 the enterprise 
data model 10 provides application-dependent dia- 
grams. As indicated by double arrow 27 the data 
model 10 can also provide application-independent 
enterprise-wide diagrams. 

One key object of the data model 10 shown in 
Fig. 1 is to establish a data model based on 
already given applications that will serve as a base 
for evolutionary integration with additional applica- 
tions. The information provided in the logical mod- 
ules given by the logical view 13. are the base for 
the application solutions and define the means of 
execution of the real relational tables. The informa- 
tion provided in the conceptional models given by 
the conceptional view 14, can be seen as a frame 
work that allow user to model their own business 
and data processing activities. 

The complete data of an existing application 
system and its relationship are presented in accor- 
dance with the present invention from two different 
points of view. 

1. From an application point of view as shown in 

Fig. 2. 

The program series 210 contains different 
application areas 220 and each application area 
contains different applications 230. This applica- 
tion point of view identifies which entities are 
used by the individual applications 230 within 



th different ^ffcation areas 220. 

The applflBron view d scrib s the data re- 
quired and the relationships betw en the data 
for all programs forming a program seri s of 

5 relational programs. Each application area 220 is 
subdivided into two data model diagrams, show- 
ing the corresponding business objects and the 
entity groups. For each application related to an 
application area detailed application data model 

to diagrams are provided. 

Fig. 2 shows how the application is broken 
down from the program series 210 over the 
application area 220 down to the detailed ap- 
plication 230. This hierarchy is used to describe 

75 the data model from the application point of 
view. 

2. From an entity point of view as shown in Fig. 
3. 

This entity point of view identifies all exist- 
20 ing entities of the application system and their 
relationships at the different levels of decompo- 
sition independently of any application functions. 

As shown in Fig. 3 in the entity view the 
highest level is the business object level 31. 
25 Underneath that there is a further decomposition 
level containing entity groups 32 underneath that 
there are data groups 33 which have different 
attributes 34 at the lowest level. The entity view 
describes the data required for the enterprises' 
30 business processes. It shows the information 
relationship through the various levels of an en- 
terprise independent of the application functions. 

Thus, in Fig. 3 the hierarchy shows the 
business object 31 as the highest level and the 
35 attribute level 34 as the lowest one. The busi- 
ness object 31 is decomposed to entity groups 
. 32, and the entity groups 32 are decomposed to 
data groups 33 which consists of attributes 34. 
Thus, this hierarchy is used to describe the data 
40 model from the entity point of view. 

Data model diagrams like those indicated by 
the boxes 15. 16, 24, and 25 in Fig. 1. show the 
entities and relationships between the entities. En- 
tities are represented in these diagrams as bubbles 
45 and entities are connected with lines to show rela- 
tionship. Entities show the entity identification IDs 
and the entity name as labels. 

In Fig. 4 there are shown different relationships 
which are used to represent and to show different 
so kinds of relationships. In the first line there is a 
one-two-one (1:1) relationship indicated by two 
bubbles left and right. One occurrence of an entity 
relates to one occurrence of another entity. A one- 
two-one relationship between two entities is shown 
55 in the diagrams with a single line and an arrow 
pointing to both one-sided entities. Thus,, in the first 
line of Fig. 4 the item ITEM has item planning data 
ITMD. 
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The one-two-many (1 : M) tyg^f relationship 
is shown in the second line of flPr4. There the 
item ITEM has multiple text data ITMT. In general, 
one occurrence of an entity relates to several oc- 
currences of another entity. A one-two-many rela- 
tionship is shown in the diagram with a doubl 
arrow pointing to the many-sided entity and a sin- 
gle arrow pointing to the on -sided entity. 

The third type of relationship is the many-to- 
one (M : 1) relationship. This is shown in the third 
line of Fig. 4 where multiple product structures 
PROD belong to one item ITEM. Thus, many oc- 
currences of an entity relates to one occurrence of 
another entity. A many-two-one relationship is 
shown in the diagrams with a double arrow pointing 
to the many-sided entity and a single arrow point- 
ing to the one-sided entity. 

The foijth type of relationship is shown in the 
forth fine of Fig. 4 as the many-two-many (M : M) 
relationship. The example shown means that one 
engineering change ENGC may effect several 
product structures PROD. Furthermore, one prod- 
uct structure PROD may be effected by more than 
one engineering change ENGC. Thus, one occur- 
rence of an entity relates to several occurrences of 
another entity and one occurrence of that second 
entity relates to many occurrences of the first en- 
tity. A many-two-many relationship is shown in the 
diagrams with two double arrows pointing to both 
many-sided entities. 

In Fig. 5 there is indicated schematically the 
relationship between the data model 50 and the 
relational data base 53. The data model 50 with its 
different entities and relationships runs preferably 
on a workstation level and provides documentation 

51 of the different model constellations and sub- 
models. Thus, data model and documentation is 
delivered by the data model. Out of the docu- 
mentation by the means of CASE TOOLS the defi- 
nition of physical implementation 52 is generated. 
This definition of physical implementation includes 
for example tables, indexes and application plans. 
This usually runs on the main frame level and is 
delivered by the application program products. Un- 
derneath this definition of physical implementation 

52 there is implemented by the customer the rela- 
tional data base 53 pertaining to the application 
system. Within data model 50 there the data model 
user can add new entities E and attributes which 
than will result in physical definitions created by 
the case tool. 

fn Fig. 6 there is schematically shown the 
application structure 60 of the program series. This 
appfication structure contains five application areas, 
the marketing applications 61, the engineering ap- 
plications 62. the production planning applications 
63, the plant operations applications 64, and the 
bas services base products 65. Furthermore, the 



application structur^60 can encompass entity 
typ s 66 and contSPIonaJ applications 67. Each 
application area encompasses business objects 
610. 620. 630. 640. 650 and entity groups 611. 

5 621, 631. 641, and 651. 

In an application structure of an application 
system like the one shown in Fig. 6 ther might 
exist already som program products in the dif- 
ferent application areas 61 to 65. Those are for 

10 example in the marketing application area the pro- 
grams Customer Order Manager 612 and the Ship- 
ping Manager 613. In the engineering application 
there might exists already the programs Production 
Definition Manager 622, Facilities Manager 623. 

is and Routings Manager 624. In the production plan- 
ning application area 63 there might exist already a 
program Material Requirements Manager 632 and 
a program Purchasing Manager 633. In the applica- 
tion area plant operations applications 64 there can 

20 exist the program Inventory Status Manager 642, 
the Receiving Manager 643. and the Production 
Order Manager 644. In the base services base 
product application area 65 there might for exam- 
ple exist programs like Security Services 652. 

25 Common Communication Management 653. Help 
Support 654, Standard Text Processing 655, and 
Item Master Data Maintenance 656. 

A somewhat different schematic representation 
of the different application areas is shown in Fig. 7. 

30 There we have six application areas marketing 761, 
engineering 762, production planning 763. plant 
operations 764, distribution 769. and business man- 
agement 768. These different areas can be consid- 
ered as a part of a wheel surrounding common 

35 enterprise support services 771 which itself sur- 
rounds the relational enterprise data base 770 for- 
ming the hub of that wheel. 

'in Fig. 8 (consisting of Fig. 8A and 8B) there 
are shown different entity types, the form of entity 

40 types 1 81 and entity types 2 82. 

In classification of data of an enterprise the first 
step is to describe business objects that are used 
in the business activities of all areas of an enter- 
prise. Because the term entity is a very general 

45 one it does not allow to classify entities by its level 
of detail and abstraction. In the data model in 
accordance with the present invention there are 
differentiated between the following types of en- 
tities: business object, entity group, data group and 

so attribute. The business object describes general 
business terms of an enterprise. They are building 
blocks of the business processes. In the program 
series data model they are decomposed to entity 
groups. In the data model in accordance with the 

55 present invention there are different objects shown 
in Fig. 8 and encompass for example the following 
business objects: business partner B-OZ. docu- 
ment B-DO, change B-CH, finance interface B-AC, 
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information B-IF. invoice B-IV^teatiog B-LO. order 
B-OR. person B-PE. plan process B-PC, 

product B-PR. requirement B-RQ, resource B-RS, 
and systems B-SY. 

The entity group is decomposed from the busi- s 
ness object. It represents a collection of entities 
that logically belong together. A customer order as 
well as a shop order or a purchase order belong to 
the business object order B-OR. Thus, in Fig. 8 to 
business object partners B-OZ. the entity groups w 
carrier E-CR. customer E-CU and supplier E-SU 
belong. To the business object document B-DO 
there belong the entity groups text E-TX, EDI cus- 
tomer order log E-EL and EDI customer order E- 
EO. To the business object change B-CH there is 
belongs the entity group engineering change E-EC. 
To the business object finapce interface B-AC be- 
long the entity groups account assignment E-AA 
and finance posting E-FP. To the business object 
information B-IF belongs the entity group message 20 
E-ME. To business object invoice B-IV belongs the 
entity group delivery E-DE, load E-LO and invoice 
checking E-IC. To the business object location B- 
LO belongs the entity group location description E- 
AD. To the business object order B-OR belongs as 25 
partly already mentioned the entity group customer 
order E-CO. MRP planned order E-PO, purchase 
order E-PU and shop order E-SO. To the business 
object person B-PE belongs the entity group au- 
thorization E-AU and to the business object plan B- 30 
PL belong the entity groups capacity plan E-CP 
and master schedule E-MS. To the business object 
process B-PC belongs the entity group routing E- 
RT. To the business object product B-PR belong 
the entity groups bill of material E-BM, case E-CA, 35 
inventory E-IN, item E-IT, item sales data E-SD and 
stock movement E-MV. The business object re- 
quirements B-RQ encompasses the entity group 
purchase request E-PR. The business object re- 
source B-RS encompasses the entity groups fa- 40 
cility E-RF and tool E-TO. Finally the business 
object systems B-SY encompasses the entity 
groups DP interface data E-ID, common system 
table E-CT. DP work space E-WS. parameter list E- 
PL, report E-RP and system control data E-SC. 45 

A data group is decomposed from an entity 
group. The data group is a selection of attribute of 
a usually normalized table. For example, the follow- 
ing data group belong to the entity group item: 
item identification, item data, item responsibility. 50 
item text reference, item routing reference, inven- 
tory summary. 

Finally the already mentioned attributes form a 
data group or several data groups or with other 
words, a data group is decomposed to attributes, i. 55 
e. consists of attributes. Attributes are often also 
called elements or data elements. 



As an exalte in Fig. 9 there- is shown the 
area of engine^Bg applications. This area includes 
business objects and entity groups as well as three 
different application programs, th product defini- 
tion manager, th facilities manager and the rout- 
ings manager. Generally the applications in this 
engineering application area maintain the basic 
records of how products are made, from what 
components they are made, and which processes 
are necessary to produce the product. Engineering 
is also concerned with determining the cost of new 
products or product changes. 

The main object of the Product Definition Man- 
ager is to maintain the basic engineering records 
that define products, their components and struc- 
tures. Other functions allow specifying planning 
factors and building profiles in keeping with a re- 
petitive production method of manufacture. This 
program also, allows to perform, basic retrievals 
against the product and the product structure. 
Product development is the main user of this ap- 
plication. The input to this area comes from mar- 
keting and plant operations. Output is directed to 
process development, production planning and 
plant operations. 

The Facilities Manager manages the informa- 
tion about a company's production resources. This 
includes work center, machine, tool and took kit 
data. Besides the definition of the resources, ca- 
pacity, cost rates, also actual status are included. 
Facilities engineering is the main user of facilities 
manager. Input to this area comes from process 
development, plant operations and costing. Output 
is directed to capacity requirements planning, plant 
operations and cost evaluation. 

The Routings Manager, functions to support 
creation of process control specifications, routings, 
quality specifications and operation descriptions. 
This also include assignment of required skills, 
facilities and their capacities, tools and material. 
Input to this area comes from product develop- 
ment. The created routings are mainly used by 
plant operations and capacity requirements plan- 
ning. 

They also serve as a base for product cost 
calculation. Process development is the main user 
of routings manager. 

Fig. 10 shows the business objects of the ap- 
plication area engineering as shown in Fig. 9. The 
diagram shows bubbles for the different business 
objects, like person B-PE. process B-PC. change 
B-CH. resource B-RS, document B-DO. product B- 
PR. location B-LO and information B-IF. Between 
these different business objects there exist different 
relationships. Those different relationships are in- 
dicated by single or double headed arrows pointing 
to the different bubbles. The meaning of these 
relationship arrows has been described already in 



5 



connection with Fig. 4. 

In Fig. 1 1 there is shown thPfflationship dia- 
gram of the entity groups of the application area 
engineering. The different entity groups authoriza- 
tion E-AU, item E-IT, purchas request E-PR. en- 
gineering change E-EC, bill of material E-BM, mes- 
sage E-ME. routing E-RT, facility E-RF, tool E-TO, 
text E-TX and location description E-AD are shown 
with their relationship arrows. Both Figs. 10 and 11 
show the entity view of the data within an area, 
namely the engineering area of an enterprise. 

In Fig. 12 there is shown the entity group bill of 
material E-BM with the product structure PROD 
and the ITEM E-IT. It shows the entity types and 
relationships of the entity group bill of material. 

A further example within the entity view shows 
the entity types and relationships of the business 
object product B-PR in Fig. 13. This diagram 
shows the business object product and entities 
belonging to it and their mutual relationships. Thus, 
th r are included the business objects invoice B- 
IV, change B-CH. information B-IF, process B-PC. 
plan B-PL, systems B-SY, requirement B-RQ. 
shown in the left-hand column and the business 
objects document B-DO. person B-PE, business 
partner B-OZ, order B-OR. resource B-RS and lo- 
cation B-LO in the right-hand column of the dia- 
gram. In the middle of the diagram there are shown 
th ntities case E-CA, bill of material E-BM, item 
E-IT, inventory E-IN, stock movement E-MV and 
item sales information E-SD. These entities and 
thes business objects have certain relations to 
each other which are indicated by the single and 
double headed arrows. 

If one takes the business object item E-IT and 
looks at it more deeply, then plenty of relationships 
and plenty of entity groups as well as data groups 
with their attributes will be visible. This visibility is 
shown in Fig. 14 on hand of example of entity 
group item E-IT. So there are included for this 
entity group item the entities MRP planned order 
E-PO, case E-CA, shop order E-SO, stock move- 
ment E-MV. DP work space E-WS, purchase re- 
quest E-PR, capacity plan E-CP, invoice checking 
E-IC and routing E-RT in the left- hand column. In 
the top line there are shown the entity groups 
inventory E-IN, item sales information E-SD, report 
E-RP and supplier E-SU. The right hand column 
shows furthermore the entity groups purchase or- 
der E-PU, message E-ME, master schedule E-MS, 
bill of material E-BM, customer order E-CO, en- 
gineering change E-EC, authorization E-AU and 
text E-TX. Between these two columns and the top 
line there is shown the item ident. ITEM which is in 
relation to the following data groups: item data 
ITMD, item match code ITMM, demand projection 
DMPJ, item routing reference ITRT, item forecast 
model FORC. item forecast base index BASt, de- 



mand history DHSHfc the left-hand part of the 
middle column. The^ht- hand part of the middle 
column shows the activity chain item ACIT, the 
item cost CSTD, line profile CFLP, peg overwrite 
5 PGOV. engineering change ENGC, item respon- 
sibility ITMR and item text referenc ITMT. 

In Fig. 15 ther is shown a further example for 
an entity type and its relationships at the exampl 
of the entity group item sales data E-SD. This 

w diagram shows the relationship to the entity group 
item E-IT and the own data groups sales variant 
and feature FEAT, sales plan SPLN. sales statistics 
STAT, sales allocation SPLP, foreign language 
SLNG which are related to the item sales data 

;5 SDAT. Furthermore, in relation witfvitem sales data 
SDAT are the entity group location description E- 
AD. the entity group text E-TX and over the data 
group customer specific data SPEC the entity 
group customer E-CU. Further data groups selling 

20 price PRIC with item quantity/discount SDIS are 
shown with the customer specific data group SPEC 
there are in relation the customer quantity/discount 
data group CDIS and the customer specific text 
reference CTXT. 

25 Generally, the description and organization of 

data and how the data is interrelated and can be 
used, reflects the information structure of an enter- 
prise. It is a representation of what is or could be 
real and can as such be seen as a model of the 

30 real world. It shows who creates, maintains, and 
uses which data. 

By the model structure of the invention, as 
described before, a user may manouver through 
the different levels up and down as well as within 

35 the levels and also between the application and 
entity views. 

Everyone in an enterprise has his perspective 
and* understanding of the company. In each enter- 
prise area, some users have a good knowledge 

40 and experience. Such a user can be considered as 
an expert. Modeling is a means of joining these 
individual views and understandings to the benefit 
of the entire enterprise. 

Most of existing applications were developed 

45 without much interaction with other functions. Dur- 
ing this process different names for the same piece 
of information were used, and the same information 
was stored and had to be maintained .in various 
sources. 

so The data within a company is valuable cor- 

porate assets and should be defined and stored 
independent of specific applications. 

The data model is not static, it grows depend- 
ing on new applications and new user require- 
55 ments. 

TTie data model of the invention provides the 
following advantages: 



6 



o Acts as a control instrum|^^or management. 
It gives an overview of orfRzation structures 
and dependencies in a graphical view, and 
shows information in a clear, distinct way. 

o Documentation of relevant enterprise data. 5 
Helps to document one of the most important 
resources of an enterprise, namely data. It 
shows interfaces and data redundancy. 

o May serve as a basis to compare the enter- 
prise's data structures to standard software 10 
systems. 

o Requires no programming skill. 

o Makes consequences of organization 
changes visible. 

o Supports communication between user 15 
groups. 

For example a data model containing infor- 
mation on enterprise data supports commu- 
nication because no data processing skill or 
particular data processing language is re- 20 
quired. 

o Platform for application designers. 

For example application designers consider 
data, functions, and process flows rather than 
columns and rows of a relational database 25 
system when designing new applications. 
The data model can also be used as a basis 
for future information systems. 

o Designers and developers can use the same 
'language' to design new applications. 30 

o Helps to identify projects only partially com- 
plete and redundant data within the integra- 
tion concept. 

o Integration vehicle for evolutionary system in- 
tegration of applications (e.g. CIM). It pro- 35 
vides a concentrated view of integration rela- 
tionships that may serve as a basis for edu- 
cation and training on the data processing 
processes in an enterprise. For example the 
entities, attributes, and relationships related 40 
to routings or process plans in the engineer- 
ing area could be used to integrate manufac- 
turing routings and process plans that are 
required in the plant operations applications 
area. 45 



c) said ap^^tion view preferably including 
application^Ras such as enterprise or busi- 
ness object, entity groups, and applications 
such as data groups, and 

d) said entity view preferably including en- 
terprise or business object and entity 
groups. 

2. Method as in claim 1, wherein said data are 
described in entity relationship diagrams con- 
taining, textual description of that entities, of 
their relationships and their usage. 

3. Method as in claim 1 or 2. wherein said data is 
grouped into submodels that combine concep- 
tual and logical enterprise data. 

4. Method as in claim 1. 2, or 3, wherein that 
application view is hierarchically organized 
from application area level over application lev- 
el down to function level. 

5. Method as in claim 1, 2, 3, or 4, wherein that 
entity view is hierarchically organized from en- 
terprise object level over entity group level, 
data group level down to attribute level. 



Claims 



1. Method for processing, handling, presenting 

data pertaining to an enterprise, especially a so 
manufacturing enterprise, in the form of a data 
model, in order to improve the understanding 
of business processes, said method containing 
the steps of arranging said data in such a way 
that said data are looked at, used and/or their 55 
relationship indicated in a manner of 

a) an application view and 

b) of an entity view; 
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